home *** CD-ROM | disk | FTP | other *** search
- From: barmar@think.com (Barry Margolin)
- Newsgroups: comp.security.misc
- Subject: Re: rexd security concerns
- Date: 5 Feb 1993 20:50:11 GMT
- Organization: Thinking Machines Corporation, Cambridge MA, USA
- Message-ID: <1kuju3INNil@early-bird.think.com>
- References: <1993Feb4.183533.16522@medtron.medtronic.com>
-
- In article <1993Feb4.183533.16522@medtron.medtronic.com> ds0007@medtronic.COM (Dale Skiba) writes:
- ># The rexd server provides only minimal authentication and is often not run
- ># by sites concerned about security.
- >
- >Could anyone share what these authentication problems are?
-
- Rexd does *no* authentication other than disallowing execution as root. It
- simply believes the uid and gid in the credentials. It doesn't even
- require the client to be in hosts.equiv or ~/.rhosts, nor does it check for
- "privileged" port use.
-
- >Also, how does this relate to rexecd. rexd is the RPC-based remote
- >execution server and rexecd if the remote execution server. These
- >appear to be two seperate C interfaces. The security breaches of
- >rexecd are well documented, but I can't find anything on rex.
-
- Rexecd requires the user's password to be transmitted, so it's about as
- secure as telnet (i.e. it allows passwords to be captured by someone
- snooping on the wire).
-
- Rshd is between rexd and rexecd in security. It uses hosts.equiv and
- ~/.rhosts and requires the use of a source port between 512 and 1024 (these
- are privileged on Unix). Assuming the hosts in hosts.equiv and all
- ~/.rhosts files are actually trustworthy, it can still be spoofed by a PC
- that can alter its address to be that of one of the trusted hosts.
-
- --
- Barry Margolin
- System Manager, Thinking Machines Corp.
-
- barmar@think.com {uunet,harvard}!think!barmar
-
-